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(54) Title: SECURITY ENFORCEMENT FOR ELECTRONIC DATA 
(57) Abstract 

Security services and policy enforcement for 

electronic data is provided through a series of trans- ^ 

actions among a server and clients using electronic ™ 
security certificates. A first client generates a digest 
from the electronic data using a one-way hashing 
algorithm, and submits a security certificate request 
containing the digest to a trusted arbitrator server, 
where the request is time stamped and logged. The 
trusted arbitrator authenticates the first client's cre- 
dentials, digitally signs the digest, creates and reg- 
isters the security certificate with digest information, 
and returns the security certificate to the first client. 
The first client combines the electronic data with the 
security cenificate to create a distribution unit. A 
second client acquires the distribution unit, extracts 
the certificate security certificate, generates a digest 
from the data using same hashing algorithm, and ei- 
ther compares the computed digest with the signed 
digest in the security cenificate. or submits a valida- 
tion request containing the security certificate serial 
number and digest to the trusted arbitrator server. If 
the digest from the second client matches the logged 
digest from the first client, the electronic data is valid. 
Depending on the certificate type and policy level, 
the trusted arbitrator server provides other services 
to the clients, such as notification of updates to the 
data, notification of improper user of the data, and 
payment for the use of the data. 




211 



r ' • 



.L"\....i 



DATA 



DATA 




VHASH 



213 



SECURfTY —209 



214 



DIGEST 

7 

-212 



215 



OtSTRlBJTKM UNfT ^ 



21 2j-| _ 9 ^ 



DtSTRlBUnON 
UNnS 



216- 



wsTWBiniofi uNrr, 



FOR THE PURPOSES OF INFORMATION ONLY 



Codes used to identify States party to the PCT on the front pages of pamphlets publishing international applications under the PCT. 



AL Albania 

AM Armenia 

AT Austria 

AU Australia 

\Z Azerbaijan 

BA Bosnia and Herzegovina 

BB Barbados 

BE Belgium 

BF Burkina Faso 

BG Bulgaria 

BJ Benin 

BR Brazil 

BY Belarus 

CA Canada 

CF Central African Republic 

CG Congo 

CH Switzerland 

CI Cdte d'Tvoire 

CM Cameroon 

CN China 

CU Cuba 

CZ Czech Republic 

DE Germany 

DK Denmark 

EE Estonia 



ES 


Spain 


LS 


Lesotho 


SI 


Fi 


Finland 


LT 


Lithuania 


SK 


FR 


France 


LU 


Luxembourg 


SN 


GA 


Gabon 


LV 


Latvia 


SZ 


GB 


United Kingdom 


MC 


Monaco 


TD 


GE 


Georgia 


MD 


Republic of Moldova 


TG 


GH 


Ghana 


MG 


Madagascar 


TJ 


GN 


Guinea 


MK 


The former Yugoslav 


TM 


GR 


Greece 




Republic of Macedonia 


TR 


HU 


Hungary 


ML 


Mali 


TT 


IE 


Ireland 


MN 


Mongolia 


UA 


IL 


Israel 


MR 


Mauritania 


UG 


IS 


Iceland 


MW 


Malawi 


US 


IT 


Italy 


MX 


Mexico 


UZ 


JP 


Japan 


NE 


Niger 


VN 


KE 


Kenya 


NL 


Netherlands 


vu 


KG 


Kyrgyzsian 


NO 


Norway 


zw 


KP 


Democratic People's 


NZ 


New Zealand 






Republic of Korea 


PL 


Poland 




KR 


Republic of Korea 


PT 


Portugal 




KZ 


Kazakstan 


RO 


Romania 




LC 


Saint Lucia 


RU 


Russian Federation 




LI 


Liechtenstein 


SD 


Sudan 




LK 


Sri Lanka 


SE 


Sweden 




LR 


Liberia 


SG 


Singapore 





Slovenia 

Slovakia 

Senega! 

Swaziland 

Chad 

Togo 

Tajikistan 

Turkmenistan 

Turkey 

Trinidad and Tobago 

Ukraine 

Uganda 

United States of America 

Uzbekistan 

Viet Nam 

Yugoslavia 

Zimbabwe 



wo 00/42492 



PCT/USOO/00716 



SECURITY ENFORCEMENT FOR ELECTRONIC DATA 

5 FIELD OF THE INVENTION 

This invention relates generally to authenticating and validating 
electronic data, and more particularly to providing security for, and enforcing 
restrictions on the use of, electronic data. 

COPYRIGHT NOTICE/PERMISSION 
10 A portion of the disclosure of this patent document contains material 

which is subject to copyright protection. The copyright owner has no objection 
to the facsimile reproduction by anyone of the patent document or the patent 
disclosure as it appears in the Patent and Trademark Office patent file or records, 
but otherwise reserves all copyright rights whatsoever. The following notice 
15 applies to the software and data as described below^ and in the drawing hereto: 
Copyright © 1997, Microsoft Corporation, All Rights Reserved. 

BACKGROUND OF THE INV ENTION 
Electronic data is inherently intangible and not easily identifiable as to its 
origin, date of creation, or what restrictions may apply to it. Computer users 
20 frequently download software applications from the Internet but in many cases 
the user cannot tell if the application is authored by the owner of the download 
site or by someone else, hifomiation, such as news articles, short stories, jokes 
and cartoons, is also available for download but the user often cannot tell if the 
information has been posted with the pcmiission of the author, or if the 
25 infomiaiion can be reused or modified without interfering with someone's 
intellectual properly rights. 

While the source of electronic data distributed on "hard" media such as 
CD-ROM or floppy disk can be identified by labeling the media, the data itself 
can be changed after the media left the author. Furthemiore. although hard 
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media is usually distributed under license, the enforcement of the licensing terms 
is difficult. 

A ''public key/private key" approach has been employed to address the 
problems of authentication and validation of electronic data. In a public 
5 key/private key scheme, the author encr>'pts the data with a pn\'ate key. The 
enciypted data can only be decrypted using the author's public key. If the 
recipient uses the public key and the use of the public key properly decrypts the 
encpy'pted data, the recipient can be cenain the data originated with the author. 
For e.xtra security, the data can be encrypted several times, usnig layers of public 
10 and private keys of both the author and recipient. The process quickly becomes 
complicated and prone to error. 

Similar encr>'ption schemes have been used to require a user to register or 
pay a fee for the use of the electronic data. The data is encrypted and the author 
only provides the decryptmg key upon registration or payment. Such limited 
15 licensing enforcement has not been successfuK however, because, among other 
reasons, many users want to review the data before registering and find the 
decr\'ption process confusing. 

Electronic certificate authorities, such as Verisign, Inc., provide for some 
authentication of electronic data by supplying individuals and companies with 
20 certificates which uniquely identify the individual or company. The author 

includes the certificate with the electronic data to identify the source of the data. 
Electronic cenificates are also frequently combined with encr\^ption of the data 
to provide a minimal level of security for the data. However, nothing in the 
ceiiificaic prevents someone from redistributing the data as their own work, or 
25 from modifying tiic data- 
One approach to memorializing the creation of electronic data uses an 
encryption routine, ofien referred to as a "one-way hash," to reduce the electronic 
data to a unique number-letter combination, or hash value, from which the data 
itself cannot be reproduced. The hash is then sent to a trusted third-party which 
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gives each hash value a sequence number based on the order in which it is 
received. If a second person hashes the same data with the same hash algorithm 
(producing the same hash value) and sends the hash value to the same third-pany 
ser\' ice, the sequence number of the second hash value is greater than that of the 
5 first. The trusted party publishes the hash values and the sequence numbers. A 
receiver of the electronic data generates the hash value and matches it against the 
pubHshed list to determine of more than one sequence number has been 
assigned. The receiver of the data is responsible for determining if the data it 
received originated with the author because the third-paily ser\Mce does not 

10 authenticate the senders. 

Thus, an author must make sure to register the hash before the electronic 
data is released publicly. Funhermore, if the second person sends the second 
hash value to a different third-party ser\Mce, the sequence numbers cannot be 
compared as they do not indicate the time and/or date of the submission. 

15 Therefore, what is needed is a mechanism to guarantee the authenticity 

and validity of electronic data, to enforce use restrictions on the data, to 
memorialize the creation of the data, and to do so without requiring the author or 
the recipient to understand complicated encryption schemes. 

SUMMARY OF THE INVENTION 

20 The above-mentioned shoncomings. disadvantages and problems are 

addressed by the present invention, which will be understood by reading and 
studying the following specification. 

Security services and policy enforcement for electronic data is provided 
through a series of transactions among a server and clients using electronic 

25 certificates which are associated with the electronic data. A first client, an author 
or originator of electronic data, generates a digest of the data using a one-way 
hashing algorithm, creates a request for a security certificate specifying type of 
security and policy lex el, and sends the security certificate request and digest to 
the ser\*er of a trusted arbitrator . The ser\'er authenticates the first client. 
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registers, timestamps and logs the certificate and digest, and returns an 
electronically signed confirmation receipt to the first client. The confirmation 
receipt contains the digest and the first client can optionally insert the receipt 
into the security certificate. The first client combines the security certificate with 
5 the data, and distributes the combination as a distribution unit. 

A second client, a user, acquires the distribution unit, extracts the data 
from the distribution unit, and generates a digest from the data using the same 
hashing algorithm. When the security ceilificate contains the digest generated 
by the first client, the second client compares the digests. If the digests match, 

10 the distribution unit acquired by the user is valid. If the digests do not match, the 
file cannot be validated. 

If the security certificate does not contain a signed confimiation receipt 
or the user cannot validate the signature, the user submits the digest to the server. 
The ser\^er compares the digest generated by the user with the logged digest. If 

15 the digests match, the distribution unit acquired by the user is valid and the 

server returns a valid message. If the digests do not match, the server returns an 
invalid message. 

Depending on the certificate type and policy level, the scrv^er provides 
other services to the clients, such as notification of updates to the data, • 
20 notification of improper user of the data, and payment for the use of the data. 

The supporting functions for the clients are automatically provided by 
modules, or components, in standard software so the author and the user do not 
have to concern themselves with complicated encr>'ption/decryption schemes. 
The server functions are additional components to server software tliat already 
25 provides electronic certificates. 

Thus, the present invention guarantees the authenticity and validity of the 
electronic data and enforces use restrictions on the data through the use of the 
certificates. Furthemiore. because the ser\''er has authenticated the first client 
prior to creating the certificate, and time stamps the digest that is generated from 
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the electronic data along with the security ceiiificate, the verification log ser\''es 
to memorialize the first client and creation lime of the data. 

The present invention describes systems, clients. ser\'ers, methods, and 
computer-readable media of varj'ing scope. In addition to the aspects and 
5 advantages of the present invention described in this summary, further aspects 
and advantages of the invention will become apparent by reference to the 
drawings and by reading the detailed description that follows. 

BRIEF DESCRIPTION OF THE DRAWINGS 
FIG. 1 shows a diagram of the hardware and operating environment in 
10 conjunction with which embodiments of the invention may be practiced: 

FlGs- 2 A and 2B are diagrams illustrating a system-level over\iew of an 
exemplar)' embodiment of the invention; 

FIG. 2C is a block diagram of one exemplary embodiment of a 
verification log for use with all exemplary enibodimeni of the invention; 
1 5 FIG. 2D is a block diagram of a one exemplar.' embodiment of a security 

certificate for use with all exemplary embodiments of the invention; 

FlGs. 3, 4, 5 A, 5B and 6 are diagrams illustrating system-level overviews 
of alternate embodiments of the invention shown in FlGs. 2A and 2B, 

FIGs. 7, 8 and 9 are flowcharts of methods to be perfonned by a server 
20 according to an cxemplar>^ embodiment of the invention; 

FlGs. 1 0, 1 1 , 1 2 A, 1 28 and 1 3 are flowcharts of methods to be 
pcrfomied by a server according to alternate embodiments of the invention; 

FIG. 14 is a Howchart of methods to be pcrfomied by an originating 
client according to all embodiments of the invention; 
25 FIG. 1 5 is a flowchart of methods to be perfomied by an acquiring client 

according to an exemplary embodiment of the invention; 

FlGs. 16, 17. IS and 19 are flowcharts of methods to be performed by an 
acquiring client according to an exemplary alternate embodiments of the 
invention; and 
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FIG. 20 is a block diagram of an exemplary embodiment of computer 
program modules that cause computers to execute the methods shown; and 
DETAILED DESCRIPTION OF THE INVENTION 
hi the following detailed description of exemplar.' embodiments of the 
5 invention, reference is made to the accompanying drawings w'hich form a part 
hereof, and in which is show^i by way of illustration specific exemplar>' 
embodiments in w^hich the invention may be practiced. These embodiments are 
described in sufficient detail to enable those skilled in the art to practice the 
invention, and it is to be understood that other embodiments may be utilized and 
10 that logical mechanical,. electrical and other changes may be made without 
departing from the spirit or scope of the present invention. The following 
detailed description is, therefore, not to be taken in a limiting sense, and the 
scope of the present invention is defined only by the appended claims. 

The detailed description is divided into five sections. In the first section, 
15 the hardware and the operating environment in conjunction with w'hich 

embodiments of the invention may be practiced are described. In the second 
section, a system level over\Mew of an exemplar>' embodiment of the invention is 
presented. In the third section, methods for an exemplarx' embodiment of the 
invention are provided. In the fourth section, a particular Internet 
20 implementation of the invention is described. Finally, in the fifth section, a 
conclusion of the detailed description is provided. 

Hardware and Operating Environment 
FIG. 1 is a diagram of the hardware and operating enviromnent in 
conjunction with w^hich embodiments of the invention may be practiced. The 
25 description of FIG. 1 is intended to provide a brief, general description of 
suitable computer hardw-are and a suitable computing environment in 
conjunction with which the invention may be implemented. Although not 
required, the invention is described in the general context of computer- 
executable instructions, such as program modules, being executed by a 

6 
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computer, such as a personal computer. Generally, program modules include 
routines, programs, objects, components, data structures, etc., that perfomi 
particular tasks or implement particular abstract data types. 

Moreover, those skilled in the art will appreciate that the invention may 
5 be practiced with other computer system configurations, including hand-held 
devices, multiprocessor systems, microprocessor-based or programmable 
consumer electronics, network PCs. minicomputers, mainframe computers, and 
the like. The invention may also be practiced in distributed computmg 
environments where tasks are performed by remote processing devices that are 
1 0 linked througli a communications network. In a distributed computing 

environment, program modules may be located in both local and remote memorv' 
storage devices. 

The exemplary' hardware and operating environment of FIG. I for 
implementing the invention includes a general purpose computing device in the 

1 5 fonn of a computer 20, including a processing unit 2 1 , a system memory 22, and 
a system bus 23 that operatively couples various system components, including 
the system memor>' 22, to the processing unit 21 , There may be only one or 
there may be more than one processing unit 21. such that the processor of 
computer 20 comprises a single central-processing unit (CPU), or a plurality of 

20 processing units, commonly referred to as a parallel processing enviromnent. 
The computer 20 may be a conventional computer, a distributed computer, or 
any other type of computer; the invention is not so limited. 

The system bus 23 may be any of several types of bus structures 
including a memory bus or memory controller, a peripheral bus, and a local bus 

25 using any of a variety of bus architectures. The system memory may also be 

referred to as simply tiie memory, and includes read only memory (ROM) 24 and 
random access memor>' (R^AM) 25. A basic input/output system (BIOS) 26, 
containing the basic routines that help to transfer information between elements 
within the computer 20, such as during start-up. is stored in ROM 24. The 
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computer 20 further includes a hard disk dnve 27 for reading from and writing to 
a hard disk, not shown, a magnetic disk drive 28 for reading from or writing to a 
removable magnetic disk 29, and an optical disk drive 30 for reading from or 
writmg to a removable optical disk 3 1 such as a CD ROM or other optical media. 
5 The hard disk drive 27, magnetic disk drive 28, and optical disk drive 30 

are connected to the system bus 23 by a hard disk drive interface 32, a magnetic 
disk drive interface 33, and an optical disk drive interface 34, respectively. The 
drives and their associated computer-readable media pro\ ide nonvolatile storage 
of computer-readable instructions, data stmctures, program modules and other 

1 0 data for the computer 20. It should be appreciated by those skilled in the art that 
any type of computer- readable media which can store data that is accessible by a 
computer, such as magnetic cassettes, flash memor>' cards, digital video disks, 
Bernoulli cartridges, random access memories (RAMs), read only memories 
(ROMs), and the like, may be used in the exemplary operating environment, 

1 5 A number of program modules may be stored on the hard disk, magnetic 

disk 29, optical disk 3 1 , ROM 24, or RAM 25, including an operating system 35, 
one or more application programs 36, other program modules 37, and program 
data 38. A user may enter commands and information into the personal 
computer 20 through input devices such as a keyboard 40 and pointing device 

20 42. Other input devices (not shown) may include a microphone, joystick, game 
pad, satellite dish, scanner, or the like. These and other mput devices are often 
connected to the processing unit 21 through a serial poii interface 46 that is 
coupled to the system bus, but may be connected by other interfaces, such as a 
parallel port, game port, or a universal serial bus (USB). A monitor 47 or other 

25 type of display device is also connected to the system bus 23 via an interface, 
such as a video adapter 4S. In addition to the monitor, computers typically 
include other peripheral output devices (not shown), such as speakers and 
printers. 
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The computer 20 may operate in a networked environment using logical 
connections to one or more remote computers, such as remote computer 49. 
These logical connections are achieved by a communication device coupled to or 
a part of the computer 20; the invention is not limited to a panicular type of 
5 communications device. The remote computer 49 may be another computer, a 
server, a router, a network PC, a chent, a peer device or other common network 
node, and typically includes many or all of the elements described above relative 
to the computer 20, although only a memor\' storage device 50 has been 
illustrated in FIG. 1. The logical connections depicted in FIG. 1 include a local- 

10 area network (LAN) 5 1 and a wide-area network (WAN) 52. Such networking 
environments are commonplace in offices, enterprise-wide computer networks, 
intranets and the Internet. 

When used in a LAN-networking enviromnent, the computer 20 is 
connected to the local network 51 through a network interface or adapter 53, 

15 which is one type of communications device. When used in a WAN-networking 
environment, the computer 20 typically includes a modem 54, a type of 
communications device, or any other type of communications device for 
establishing communications over the wide area network 52, such as the Internet. 
The modem 54. which may be internal or external, is connected to the system 

20 bus 23 via the serial port interface 46. In a networked environment, program 

modules depicted relative to the personal computer 20, or ponions thereof, may 
be stored in the remote memory storage device. It is appreciated that the 
network connections shown are exemplary and other means of and 
communications devices for establishing a communications link between the 

25 computers may be used. 

The hardware and operating environment in conjunction with which 
embodiments of the invention may be practiced has been described. The 
computer in conjunction with which embodiments of the invention may be 
practiced may be a conventional computer, a distributed computer, or any other 
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type of computer; the invention is not so limited. Such a computer typically 
includes one or more processing units as its processor, and a computer-readable 
medium such as a memory. The computer may also include a communications 
device such as a network adapter or a modem, so that it is able to 
5 communicatively couple to other computers. 

System Le\-el Overview 
A system level overview of the operation of an exemplary' embodiment 
of the invention is described by reference to FIGs. 2A and 2B. The exemplar\^ 
embodiment is implemented in an wide-area networking environment 52 having 

1 0 a ser\'er computer, such as remote computer 49, and two user or client 

computers, such as local computer 20, all of which are shown m FIG. 1 and 
described in the previous section.. Alternate exemplary embodiments are 
described with reference to FIGs. 3, 4, 5A, 5B and 6. 

The exemplary embodiments of the invention are described in terms of 

15 transactions occurring among three parties in support of the exchange of 

electronic information, such as text documents, images, executable code, or any 
other electronic data exchanged between a first pany and a second party. The 
first party originates the information which is subsequently acquired by the 
second pany. The first party and the second party rely on a trusted third party 

20 arbitrator to perfonn ser\ ices in conjunction with the creation, receipt and use of 
the information. 

In a first exemplar>' embodiment shown in FIGs. 2A and 2B, the trusted 
arbitrator authenticates the first party and validates the information. In a second 
exemplary' embodiment shown in FIG. 3. use of the infoimation by the second 
25 party is monitored on behalf of the first paity. In a third exemplar>' embodiment 
shown in FIG. 4, the licensing of the infomiation to the second party is 
monitored on behalf of the first party. In a fourth exemplary embodiment shown 
in FIGs. 5 A and 58, the trusted arbitrator manages the communication of 
updates to the information by the first party to the second party. In a fifth 

10 
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exemplary embodiment shown in FIG. 6, the tnisied arbitrator manages 
registration and payment for the information by the second party on behalf of the 
first party. 

All communication between the parties and the imsied arbitrator is secure 
5 so that no other pany can pretend to be the trusted arbitrator and so that the 
infonnation exchanged is protected. 

With reference to FIG. 1, the trusted arbitrator of the following 
exemplarx' embodiments can be, for example, the serx'er computer 49, the first 
and second parties can be client computers 20, and the wide area network 52 can 

10 be the Internet. Additionally, the trusted arbitrator is described in the exemplar.' 
embodiments as storing and retrieving information. Such infonnation can be 
stored on any of the types of computer-readable media described in the previous 
section and can be arranged in any type of data storage format, such as indexed 
flat files or various types of data bases well known to one of skill in the art. 

15 The trusted arbitrator can be any on-line server which is trusted by the 

first and second parties. Because the- interchange among the parties is based on a 
digital security certificate which specifies a security sen'ice or policy, or a 
combination thereof, "trusted certificate authorities," such as VeriSign, Inc.. 
AT&T Certificate Sendees, and Microsoft Root SGC Authority, can act as the 

20 trusted arbitrator by expanding their existing ser\'ices. A digital security 

certificate ser\'es to uniquely identify the holder. Currently, a trusted certificate 
authority verifies the identity of a party requesting a digital security certificate 
using infonnation such as a social security number, addresses, and credit card 
information. VeriSign, for example, uses Equifax credit information to 

25 authenticate a requesting party. The trusted certificate authority can optionalh' 
digitally sign the security certificate which decreases the possibility of fraud. 
The certificate holder attaches the certificate to its documents, both files and 
data, to authenticate the infonriation as having originated with the certificate 
holder. As the basics of trusted certificate authorities and digital certificates are 

1 1 
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well known to one of skill in the art, the following sections discuss the 
inx'ention's novel application of the concepts. 

For purposes of illustration, the information in the exemplary' 
embodiments is a computer application created by the first party, a software 
5 vendor such as a developer or company, and acquired by the second pany, a 
computer user. The computer application is distributed in a distribution unit, 
such as a compressed "cabinet" file frequently used to distribute applications for 
the N'licrosoft Windows family of operating systems, which contains all the files 
necessar\' to run the application. 

10 In the following exemplar>' embodiments, the temi "vendor" is used 

interchangeably to mean the actual vendor (individual or company) and the 
vendor's computer executing software that perfomis the vendor operations as 
described below. Similarly, the term "user" is used interchangeably to mean the 
user (individual or company) and the user's computer executing software that 

1 5 performs the user operations as described below. The meaning will be clear 
from the context of the sentence- 
Referring first to FIG. 2A, the registration transactions occurring between 
the software vendor 201 and the trusted arbitrator 203 are described. It is 
assumed that the vendor 201 has previously registered with the trusted arbitrator 

20 203 using current common methodologies. Additional details on the registration 
process are described in conjunction with FIG. 7 below. 

The software vendor generates a digest 2 1 5 of the data to be 
authenticated 21 1 using a one-way hashing algorithm 213 (transaction I). A 
request 205 for a security certificate specifying the desired security ser\'ices and 

25 policies is sent to the trusted arbitrator 203 (transaction 2). The request 205 also 
contains the digest 215. 

The trusted arbitrator 203 time-stamps the information it receives and 
authenticates the software vendor's 201 credentials contained in the request 205, 
signs the digest 21 5, and creates a unique security certificate 209 for the vendor 

12 
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201 . If the vendor's 201 credentials contained in the request 205 cannot be 
authenticated or the vendor 201 does not have permission for the requested 
security ser\Mces or policies, the trusted arbitrator 203 will return an invalid 
request message (not shown). 
5 The trusted arbitrator 203 authenticates the software vendor's. 201 

credentials from a vendor registry 207 (transaction 3). The trusted arbitrator 203 
creates the security certificate 209 from information in the request 205 from the 
vendor 201. The trusted arbitrator 203 registers the security certificate 209 in a 
security ceitificate registr\' 204 (transaction 4). The trusted arbitrator 203 

10 ' registers the tmiestamp. data file's 21 1 name, security ceitificate's 209 serial 

number and digest 215 into the verification log 208 (transaction 5). The trusted 
arbitrator 203 adds the security certificate's 209 serial number to the list of 
security certificates 209 owned by the vendor 201 (transaction 6). The data in 
the vendor registry 207. verification log 208 and security certificate log 204 are 

15 read-only and cannot be changed once entered. The trusted arbitrator 203 returns 
the security certificate 209 and receipt 206 to the software vendor 201 
(transaction 7). In an alternate embodiment, the trusted arbitrator 203 includes a 
digitally signed digest 214 in the security certificate 209 (shown in phantom). 

In the embodiment shown in FIG. 2 A, the software vendor 201. acquires a 

20 single security certificate 209 for one data file 21 1 and creates a distribution unit 
212 consisting of the data file 21 1 and its corresponding security certificate 209 
(transaction S). in an alternate embodiment shown in transaction 9, the software 
vendor 201 creates a nested distribution unit 216 which contains multiple 
distribution units 212. 

25 In two aUematc embodiments not shown in FIG. 2A, the software vendor 

201 acquires multiple security certificates and stores them along with their 
con-csponding data files in a single distribution unit, or acquires a security 
certificate for the distribution unit itself and packages the security cenificate 
along with the distribution unit. 



13 



wo 00/42492 



PCT/USOO/00716 



Referring next to FIG. 2B, the authentication and vaHdation transactions 
occurring between the user 202 and the trusted arbitrator 203 when the user 202 
acquires the distribution unit 212 containing the data 21 1 and security cenificate 
209 are described. The user 202 acquires the distribution unit either directly 

5 from the vendor 20 L through a software distributor, or from a location on a 
wide-area network, such as the Internet (transaction 1 ). The presence of the 
security certificate 209 notifies the user 202 that the vendor has been 
authenticated by a trusted arbitrator. The user 202 validates the data 21 1 
contained in the distribution unit 212 by generating a second digest 223 from the 

10 data 21 1 using the identical one-way hashing algorithm 213 used by the software 
vendor 201 (transaction 2). In an embodiment in which the security certificate 
209 contains a signed digest 214 from the trusted arbitrator 203, the second 
digest 223 is compared with the signed digest 214. If they match, no action is 
required from the trusted arbitrator 203 and the data is considered valid 

1 5 (transaction 3). If there is no match, the user 202 can consider the data 2 1 1 

invalid or can optionally verify the data 21 1 with the trusted arbitrator that issued 
the security certificate 209. 

When the security certificate 209 does not contain a signed digest 214 or 
the user 202 wants to validate the data 21 1 with the trusted arbitrator, the user 

20 202 submits a validation request 224 containing the security certificate's 209 

serial number and the second digest 223 to the trusted arbitrator 203 (transaction 
4). 

The trusted arbitrator 203 reads the entr>' in the verification log 208 that 
corresponds to the serial number of the security certificate 209 and compares the 
25 first digest 215 stored in the verification log 208 with the second digest 223 send 
by the user 202 (transaction 5). If the serial number is not found, the trusted 
arbitrator 203 returns a message to the User 202 that the data 212 is invalid (not 
shown). 
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If the first and second digests match, the trusted arbitrator 203 returns a 
message 225 to the user 202 confirming the validity of the distribution unit 212 
(transaction 6). If the first and second digests do not match, the data in the 
distribution unit 212 has been changed since the first digest 215 was generated 
5 and the tmsted arbitrator 203 returns a message that the distribution unit 212 is 
invalid. 

FIG. 2C illustrates one exemplary' embodiment of a verification log data 
structure 250 having four data fields: file name 251, timestamp 252, security 
ceitificate serial number 253. and data file digest 254, FIG. 2D illustrates one 

10 exemplai-y embodiment of a security certificate data structure 260 comprising a 
serial number field 261 and one or more security services fields 262. 

Different types of security ser\'ices and policy levels can be requested 
from the trusted arbitrator. The request 205 for a security certificate that 
provides authentication and validation of a file has been described in conjunction 

1 5 with FIG. 2A. Alternate embodiments that use four other types of security 

services (copyrighting, licensing, subscription, and consignment) are described 
next. These security certificates ser\'e lo authenticate and validate a file as does 
the previously described security certificate, but they also cause the trusted 
arbitrator 203 and user 202 to perform other ser\'ices after the distribution unit is 

20 acquired by the user 202. The vendor 201 can have more than one type of 
security service permission registered with the trusted arbitrator 203. The 
transactions invoked by the different security ser\'iccs and policies are described 
next. 

In the following alternate embodiments, the software vendor 201 
25 requests a security certificate specifying the different security servMces and 
policies in the same fashion as shown in FIG. 2A for security certificate 205. 
The remainder of the transactions shown in FIG. 2A also occur as previously 
described. The transactions described next occur after transactions 1 through 9 
of FIG. 2A. 

15 
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Turning now to FIG. 3, the transactions among the vendor 201, the user 
202 and the trusted arbitrator 203 are described when the user 202 acquires a 
distribution unit 312 containing the data 21 1 and a security certificate 309 
specifying the copyright service (transaction 1). When the user 202 performs an 
5 action on the data 21 1 which invokes the copyright poHcy in the security 
certificate 309, depending to the copyright policy specified in the security 
certificate 309, either 1) the user is warned and not permitted to perform the 
action if it is against the copyright poHcy, 2) the vendor 201 is notified through 
the trusted arbitrator 203 that the action on the data 21 1 has happened; 3) 

1 0 pennission is requested from the vendor 201 through the trusted arbitrator 203 to 
perform the action on the data 21 1 ; or 4) the user is allowed to perform the 
action on the data 211. 

In the second case where the copyright pohcy specifies that the vendor 
201 be notified of a copyright action, the user 202 notifies the trusted arbitrator 

1 5 203 with a notification message 301 containing the serial number of the security 
certificate 309 (transaction 2). The trusted arbitrator 203 finds the security 
certificate 309 in the security certificate registr\' 204 and checks the copyright 
policy in the security certificate 309. If the policy states that the vendor 201 be 
notified, the trusted arbitrator 203 finds the vendor information in the vendor 

20 registry 207 (transaction 4) and sends a notification message 303 to the vendor 
201 (transaction 5). The trusted arbitrator 203 registers that the user 202 has 
properly notified the vendor 201 in the user registry 302 (transaction 7). The 
trusted arbitrator returns a receipt 305 signifying that the vendor 201 has been 
notified and the user 202 can perfomi the action on the data 21 1 (transaction S). 

25 In the third case where the copyright policy specifies that the vendor 201 

must give pemiission for a copyright action, the user^s 202 software notifies the 
trusted arbitrator 203 with a notification message 301 containing the serial 
number of the security cenificate 309 (transaction 2). The trusted arbitrator 203 
finds the security certificate 309 in the security certificate registry 204 and 
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checks the copyright poHcy in the security certificate 309. If the policy states 
that the vendor 201 must give permission, the trusted arbitrator 203 finds the 
vendor infomiation in the vendor registr\' 207 (transaction 4) and sends a 
notification message 303 to the vendor 201 (transaction 5). The- vendor 201 
5 receives the notification 303 and grants or denies permission for the action. The 
vendor 201 sends the permission granted or denied message 304 to the trusted 
arbitrator 203 (transaction 6). The trusted arbitrator 203 registers that the user 
202 has be granted or denied the action by the vendor 201 in the user registry 
302 (transaction 7). The trusted arbitrator returns a receipt 305 that the vendor 

10 201 has granted or denied permission which is enforced by the user 202. 

Turning now to FIG. 4, the transactions among the vendor 20 L the user 
202 and the trusted arbitrator 203 are described when the user 202 acquires a 
distribution unit 412 containing the data 21 1 and a security certificate 409 
specifying the licensing service (transaction 1). When the user 202 uses the data 

15 211, the presence of a security certificate 409 which specifies the license policy 
for the data 21 1 is determined. If the user 202 has a valid license for the data 
211, the user 202 can continue. 

If the user 202 does not have a valid license for the data 2 1 1 , a license 
renewal request message 401 containing the serial number of the security 

20 cenificate 409 is sent to the trusted arbitrator 203 (transaction 2). The trusted 

arbitrator 203 finds the security certificate 409 in the security cenificate registry 
204 and checks the licensing policy in the security certificate 409 (transaction 3). 
The trusted arbitrator 203 checks if the user's 202 license has been revoked in 
the user registry 302 (transaction 4). 

25 If the license has been revoked, the trusted arbitrator 203 returns a 

message to the user 202 that their license has been revoked which causes access 
to the data 211 to be denied. If the user's 202 license has not been revoked and 
the licensing policy states that the vendor 201 renew the license, the trusted 
arbitrator 203 finds the vendor infomiation in the vendor registry 207 
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(transaction 5) and sends a license renewal request message 402 to the vendor 

201 (transaction 6). The vendor 201 can either renew the license or not and 
return a renewal message 403 to the trusted arbitrator 203 (transaction 7). The 
trusted arbitrator 203 updates the user registr>^ 302 with the renewal infomiation 

5 (transaction 8). If the vendor 201 did not renew the license, the tioisted arbitrator 
203 informs the user 202 that the license has not been renew-ed and access to the 
data 21 1 is denied. If the vendor 201 rencw-ed the license, the trusted arbitrator 
203 sends the license renewal 404 which contains the registration ID or keycode 
to unlock the software (transaction 9). The user 202 can use the data 21 1 in 
10 accordance with the temis of the license. 

The subscription security ser\ ice and related transactions are shown in 
FIGs. 5 A and 5B. FIG 5 A shows the transactions among the vendor 20 K the user 

202 and the trusted arbitrator 203 when the user 202 acquires a distribution unit 
512 containing the data 21 1 and a security cenificate 509 specifying the 

15 subscription ser\'ice (transaction 1). The user 202 registers for future updates to 
the data 211 by sending a subscribe message 501 containing the serial number of 
the security certificate 509 to the trusted arbitrator 203 (transaction 2). 

The trusted arbitrator 203 finds the security certificate 509 in the security 
certificate registry 204 and checks the subscription policy in the security 

20 certificate 509 (transaction 3). The trusted arbitrator 203 adds the user 202 as a 
subscriber to the data 21 1 listed in the security certificate 509 to the user registry 
302 (transaction 4). The trusted arbitrator 203 returns a subscription receipt 502 
to the user 202 (transaction 5). 

Update notification for multiple subscribed users 520, 521, 522 is 

25 illustrated in FIG. 5B. When the vendor 201 updates the data 211, i.e., creates 
data 231, the vendor 201 computes a new digest 215 using the one-way hash 
algorithm 213. The vendor 201 sends an updated subscription message 503 
which contains the serial number of the original security certificate 509 and the 
new digest 215 (transaction I). The trusted arbitrator 203 validates the vendor's 
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201 credentials in the vendor registr>' 207 (transaction 2). The trusted arbitrator 
203 updates the security certificate registry 204 to record that a new subscription 
of the data 21 1 occurred (transaction 3). The trusted arbitrator 203 creates a list 
of all users 202 subscribed to the data 21 1 from the user regisir>' 302 (transaction 
5 4). A subscription update receipt 504 containing the new security certificate 510 
and optionally containing the list of users 520-522 who are subscribed to the data 
211 is returned to the vendor 201 (transaction 5). The vendor 201 creates a new 
distribution unit 5 1 3 from the data 23 1 and security certificate 5 1 0 and publishes 
it in the same manner as the original distribution unit 512 (transaction 6). The 

10 trusted arbitrator 203 infomis the users 520-522 that the data 21 1 which they 
subscribed to has been updated (transaction 7). The users 520-522 retrieve the 
new^ distribution unit 513 (transaction S). 

A security certificate 609 that specifies the consignment service and 
related transactions among the vendor 201, the user 202, and the trusted 

15 arbitrator are shown in FIG. 6. The user 202 acquires a distribution unit 612 

containing the data 21 1 and a security certificate 609 specifying the consignment 
ser\'ice (transaction 1 ). When the user 202 uses the data 21 1, the presence of 
security certificate 609 specifying a consignment policy for the data 21 1 is 
detemiined. If the user 202 has paid for the data 211, the user 202 can continue. 

20 

If the user 202 has not paid for the data, a payment message 601 
containing the serial number of the security certificate 609 and payment 
information is sent to the trusted arbitrator 203 (transaction 2). The trusted 
arbitrator 203 finds the security certificate 609 in the security certificate registr>^ 
25 204 and checks the consignment policy in the security certificate 609 

(transaction 3). The trusted arbitrator 203 updates the user registry 302 that the 
user has paid for the distribution unit 612 (transaction 4), The trusted arbitrator 
returns a receipt 602 containing the registration ID or keycode to unlock the data 
21 1 (transaction 5). The trusted arbitrator sends the payment infonnation 603 to 
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the vendor 201 (transaction 6). The trusted arbitrator updates the vendor registr>' 
207 that a payment for data 211 has been made (transaction 7). 

Further details on differing types of security services and use poHcy 
levels provided by the trusted arbitrator and the intermixmg of different security 
5 services and policies in a security certificate are discussed in the next section. 
The use of types of security cenificates other than described above will be 
readily apparent to one skilled in the art and are contemplated as within the 
scope of the invention. 

The system level overview of the operation of exemplary embodiments 

10 of the invention has been described in this section of the detailed description. A 
series of transactions among parties that provide security ser\'ices and poHcy 
enforcement for the distribution and use of electronic data has been described. 
For sake of clarity a simplified version of protecting software applications 
distributed across the Internet has been described. The invention is not, 

15 however limited to use in distributing computer software across a network but 
will be immediately perceived as applicable to any exchange of files or 
documents which must be authenticated or validated in some fashion, such as 
legal papers, tax filings, employment records, or the like. Furthermore, although 
the distribution unit used for illustrative purposes in this section contains a single 

20 distribution unit, the ability to have multiple distribution units in a distribution 
unit, or to nest distribution units is also contemplated by the invention. 

Methods of an Exemplary Embodiment of the Invention 
In the previous section, a system level over\'iew of the operation of an 
exemplan,' embodiment of the invention was described. In this section, the 

25 particular methods perfomied by a server or remote computer of such an 

exemplar}^ embodiment are described by reference to a series of flowcharts. The 
methods to be perfomied by the ser\'er computer constitute computer programs 
made up of computer-executable instructions. Describing the methods by 
reference to a flowchait enables one skilled in the an to develop such programs 
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including such instructions to carry out the methods on suitable computerized 
servers (the processor of the clients/ser\'er executing the instructions from 
computer-readable media). Also in this section, the particular methods 
perfonned by two client (vendor and user) or local computers of such an 
5 exemplary embodiment are described by reference to a series of flowcharts. The 
methods to be perfonned by the client computers constitute computer programs 
made up of computer-executable instructions. Describing the methods by 
reference to a flowchart enables one skilled in the art to develop such programs 
including such instructions to carry out the methods on suitable computerized 

10 clients (the processors of the clients executing the instructions from computer- 
readable media). 
Trusted Arbitrator Server 

FIGs- 7, S, 9, 10, lU 12A, 12B and 13 illustrate flowcharts of methods to 
be perfonried by a server computer providing the services of the trusted 

15 arbitrator according to the exemplary embodiments of the invention discussed in 
the previous section in conjunction with FIGs. 2A, 2B, 3, 4, 5 and 6. These 
methods are inclusive of the steps or acts required to be taken by the trusted 
arbitrator server computer using the components discussed in the previous 
section. 

20 Beginning with FIG. 7, when the vendor first registers with the trusted 

arbitrator, the trusted arbitrator receives a vendor registration along with a 
possible payment (step 701). The trusted arbitrator checks the credentials of the 
vendor to see if they are valid (step 702). If the credentials do not match, then 
the trusted arbitrator returns an invalid registration message (step 703). If the 

25 credentials match, the trusted arbitrator transfers the payment from the vendor if 
required (steps 704 and 705). The trusted arbitrator adds the vendor to the 
vendor registry along with the ser\aces the vendor has registered (step 706). The 
trusted arbitrator returns a confirmation receipt to the vendor (step 707). 
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In one embodiment, the trusted arbitrator places a "cookie" that is 
specific to the arbitrator and the vendor's computer on the vendor's computer and 
stores the cookie contents in the vendor registry for future authentication of the 
vendor, hi an aUemate embodiment, the trusted arbitrator transmits a password 
5 unique to the vendor and stores the password in the vendor registry so that the 
vendor can be authenticated using the password. 

When the vendor requests a security certificate from the trusted arbitrator 
(referring to FIG. 8), the trusted arbitrator receives a certificate request and 
digest (step 801 ). The trusted arbitrator records the time and date of receipt (step 

10 S02). The vendor is authenticated against the vendor registry (step 803). If 

vendor cannot be authenticated, then the request is from an invalid vendor (step 
804). The trusted arbitrator searches the vendor registry for the correct vendor 
(step 805) and notifies them of the invalid request (step 806). The invalid vendor 
is also notified with the reason their request was not granted. 

15 If the vendor is valid, then the trusted arbitrator verifies that the vendor is 

permitted to declare the security service requested (step 807). If the vendor does 
not have permission to declare the security ser\Mce requested, the trusted 
arbitrator returns an invalid security certificate message (step 808). 

If the request is valid, then the trusted arbitrator creates the security 

20 certificate by generating a unique security certificate number (step 809); 
embedding the time and date stamp (step 810); filling in the appropriate 
information from the request and the vendor registr>' (step 811); and optionally, 
embedding the digitally signed digest into the certificate (step 812 shown in 
phantom). The trusted arbitrator writes the security certificate information to the 

25 security certificate registry (step 813); writes the security certificate serial 
number and digest to the verification (digest) log (step 814); and adds the 
security certificate serial number to the vendor's entry in the vendor registry 
(step 815). A receipt containing the security certificate is returned to the vendor 
(step 815). 
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Turning now to FIG. 9, under certain circumstances as described above 
and in more detail below, when the user needs to validate the data received in a 
distribution unit, the trusted arbitrator receives a validation request containing 
the security certificate serial number and computed digest from the user (step 
5 901). The trusted arbitrator queries the verification log for the digest of the 
security cenificate serial number (step 902). If the security certificate serial 
number is not found in the verification log (step 903) or if the digests do not 
match (step 904), then the trusted arbitrator returns an invalid data receipt (step 
905). If the digests match, then the data is valid and the trusted arbitrator returns 

10 a valid data receipt (step 906). When the user of data associated with a 

security certificate specifying the copyright service invokes the notification or 
permission policy through an action, the trusted arbitrator receives a copyright 
notification message containing the security certificate serial number to the 
trusted arbitrator (step 1001). The trusted arbitrator checks if the security 

15 certificate serial mimber is a valid number (step 1 002) in the security certificate 
registry. If not, it is an invalid security certificate serial number (step 1003). 
The user is notified that the trusted arbitrator could not find the serial number 
(not shown). Under these circumstances, any copyright policies on the 
document cannot be enforced so the data is treated as if it is not copyrighted. 

20 For a valid security certificate, the trusted arbitrator checks if the secunty 

certificate specifies the copyright service (step 1004). If not, the trusted 
arbitrator returns a message telling the user that the file is not copyrighted (step 
1005). If copyright information exists, then the trusted arbitrator queries the 
vendor registry for the copyright contact information (step 1006). The trusted 

25 arbitrator notifies the vendor contact that the copyright policy has been invoked 
by the user and updates the user registry (step 1007). 

If pemiission from the vendor is not required (step 1008), then the trusted 
arbitrator grants pennission to the user (step 1009), else the trusted arbitrator 
waits for the author to grant or deny pennission (step 1010). The trusted 
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arbitrator adds the vendor's reply to the user registr\^ (step 101 1) and sends a 
message to the user either granting (step 1009) or denying (step 1012) 
pemiission to continue. 

As described above and in more detail below, when the user attempts to 
5 use data which is associated with a security certificate specifying the license 

service and the license is invalid, the trusted arbitrator receives a license renewal 
request containing the security certificate serial number (step 1101 in FIG. 1 1 ). 
The trusted arbitrator checks if the security certificate serial number is a valid 
number (step 1 102) in the security certificate registry. If not, it is an invalid 

10 security certificate serial number (step 1 103). The user is notified that the 

Trusted arbitrator could not find the serial number (not shown). Any license 
policies on the document cannot be enforced and the data is treated as if it is not 
subject to licensing. 

When the security certificate is valid, the trusted arbitrator checks if the 

15 security certificate specifies the license service (step 1 104). If not, the trusted 
arbitrator returns a message telling the user that the file is not licensed (step 
1 105). Iflicense infomiation exists, 

the trusted arbitrator checks if the user's license to use the software has been 
revoked in the user registr\' (step 1 106). If the user's license has been revoked, 

20 the trusted arbitrator returns a license revoked message to the user's computer 
(step 1 107) which results in the user being unable to access the data. 

If the license is not revoked, the trusted arbitrator queries the vendor 
registry for the licensor information (step 1 108). The trusted arbitrator requests a 
license renewal from the licensor and waits for the licensor to renew or revoke 

25 the license (step 1 109). The trusted arbitrator adds the licensor's reply to the 

user registr>' (step 1110) and either revokes the license as described immediately 
above (step 1 112) or renews the license by sending a registration ID or keycode 
to unlock the software (step 1 1 13). 
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As shown in FIG. 12A, when the vendor modifies periodically-updated 
data associated with a security certificate specifying the subscription service 
modifies the data, the vendor notifies the trusted arbitrator with a subscription 
update request containing the newly calculated digest of the modified material 
5 (step 1201). The trusted arbitrator time and date stamps the request (step 1202) 
and checks the vendor's credentials to see if the vendor is valid (step 1203). If 
the vendor is not valid (step 1204), the trusted arbitrator searches for the real 
vendor in the vendor registry (step 1 205) and alerts the real vendor (step 1206). 
If the vendor is valid, the trusted arbitrator checks if the subscription 

10 update request is for an existing security certificate (step 1207). If not, the 

trusted arbitrator returns a message that the subscription update request is invalid 
(step 1208). If the subscription update request is valid, the trusted arbitrator 
updates the edition information in the verification (digest) log (step 1209), 
embeds the time and date stamp (step 1210), and, optionally, digitally signs the 

15 new digest and inserts the signature in the security certificate (step 1211 shown 
in phantom). The trusted arbitrator updates the serial number of the security 
certificate in the security certificate registry (step. 1212), creates a new entry in 
the verification (digest) log (step 1213), and adds the new security certificate 
serial number to the vendor's security certificates in the vendor registry.(step 

20 1214). The trusted arbitrator returns a receipt containing the updated security 
certificate (step 1215). The trusted arbitrator searches the user's registry for all 
users subscribed to the data (step 1216) and notifies them of the updated 
document (step 1217). 

Continuing on to FIG. 12B, the user of data associated with a security 

25 certificate specifying the subscription ser\Mce can subscribe to be notified of 

updates to the data by sending a user subscription request to the trusted arbitrator 
(step 121 S). The trusted arbitrator checks if the user subscription request is for 
an existing security certificate (step 1219). If not. the trusted arbitrator returns a 
message that the data does not exist (step 1220). 
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When the data does exists, the trusted arbitrator checks if the security 
certificate contains the subscription service block (step 1221). If not, the trusted 
arbitrator returns a message that the data cannot be subscribed to (step 1222). If 
the security certificate contains a subscription service block, the trusted arbitrator 
5 updates the user registry for subscribers to the security certificate serial number 
(step 1223) and returns a subscription receipt (step 1224). 

As described above and in more detail below, when the user of data 
associated with a security certificate that specified the consignment service 
receives the data without a valid license to use the data, the user can purchase the 

10 data. FIG. 13 illustrates the method used by the trusted arbitrator if the user 
chooses to purchase the data. The trusted arbitrator receives consignment 
payment request containing the security certificate serial number and payment 
information (step 1301). The trusted arbitrator checks if the security certificate 
serial number is a valid number (step 1302) in the security certificate registry. If 

1 5 not, it is an invalid security certificate serial number (step 1303), The user is 
notified that the trusted arbitrator could not find the serial number (not shown). 
Any consignment policies on the document cannot be enforced and the data is 
treated as if it is not on consignment. 

For a valid certificate, the trusted arbitrator checks if the security 

20 certificate specifies the consignment service (step 1304). If not, the trusted 

arbitrator returns a message telling the user that the file is not on consignment 
(step 1305). If consignment information exists, the trusted arbitrator withdraws 
payment from an account maintained by the user (step 1306) and updates the 
user registr\' to indicate that the user has paid (step 1307). The trusted arbitrator 

25 returns a registration ID or keycode to unlock the software (step 1308), sends a 
payment to the vendor (step 1309) and updates the account information in the 
vendor registry (step 1310). 
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Vendor Client 

A flowchart of a method to be performed by a client computer on behalf 
of a vendor according to the exemplary embodiments of the invention is shown 
in FIG. 14. The method is inclusive of the steps or acts required to be taken by 
5 the vendor client computer using the components discussed in the previous 
section. 

The vendor client computer applies a one-way hashing algorithm to the 
electronic data to create a digest of the data (step 1401). If the client is updating 
existing data associated with a security certificate specifying the subscription 

10 service (step 1402), the vendor client computer creates a subscription update 
request from the vendor's credentials and desired types of ser\aces and policy 
levels, and submits the request with the digest to the ser\'er (step 1403). If the 
data is not a subscription update of existing data, the vendor client computer 
creates a new security certificate request from the vendor's credentials and 

15 desired types of services and policy levels and submits the request with the 
digest to the ser\'er (step 1404). 

In either case, when the security certificate is received from the trusted 
arbitrator (step 1405), the vendor client computer combines the security 
cenificate with the data to form a distribution unit (step 1406). Distribution 

20 units may optionally be combined with other distribution units to form nested 
distribution units (step 1407 shown in phantom). The vendor client distributes 
the distribution unit containing the data and security certificate (1408). 
User Client 

FIGs. 15, 16, 17, IS and 19 illustrate flowcharts of methods to be 
25 perfonned by a client computer on behalf of a user according to the exemplary 
embodiments of the invention. These methods are inclusive of the steps or acts 
required to be taken by the user client computer using the components discussed 
in the previous section. 
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Wlien a distribution unit is loaded, the user client computer extracts the 
security certificate from the distribution unit to deiemiine which ser\'ices to 
perform. For example, if the certificate allows a thiny-day trial period but 
requires payment after that, the client notes the date the infonnation is installed 
5 so that it can alert the user when the time period has expired. Other additional 
operations necessary to support the security services and policy enforcement will 
be readily apparent to one of skill in the art upon reading the detailed description 
of the various security types and policy levels below. The data can require the 
client perfonn an installation process prior to the data being used or if the 

10 distribution unit is a compressed file, the client must uncompress the data. If 

textual data is distributed in word processor compatible distribution unit, such as 
a Microsoft Word document, no additional processing is required. 

Thus, FlGs. 15, 16, 17, 18 and 19 all begin with the acquisition of a 
distribution unit and the extraction of the security certificate to determine the 

1 5 security services and policies specified therein. The method used by the user 
client computer's is dictated by the type of security certificate. Because the 
security serx'ices and policies can be combined in various permutations, the 
methods described below are also combined as required by the specific security 
certificate. 

20 Turning first to FIG. 1 5 and a distribution unit containing a security 

certificate w-^hich specifics the validation ser\Mce (step 1 501), the user client 
computer validates the data by extracting the security certificate (step 1502) and 
computing a digest from the data using a one-way hashing function (step 1503). 
If the security certificate contains a signed digest from a trusted arbitrator that 

25 the user client computer can verify as correct (step 1504), the user client 

computer will compare the signed digest with the computed digest (step 1505). 
If the digests match (step 1506), the data are valid (step 1507), else the data are 
invalid (step 1508). 
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If there is no signed digest in the file, then the user cHeni computer sends 
a validation request message containing the security certificate serial number and 
the computed digest to the trusted arbitrator (step 1509). If the trusted arbitrator 
returns a valid receipt (step 1510), the data are valid (step 1511), else the data are 
5 invalid (step 1512). 

As shown in FIG. 16, if the security certificate specifies the copyright 
seiA'ice, the user client computer monitors the user's actions on the data (step 
1603). If the user's actions invoke the copyright policy (step 1604), the user 
client computer checks to determine if the action is in accordance with the 

1 0 copyright policy (step 1605). If the action is denied by the copyright policy, the 
user^s action is disallowed (step 1606) and optionally the user is notified as to 
the reason (step 1607). If the user's action requires that the vendor be notified 
(step 1608) or that permission be requested from the vendor (step 1609), the 
vendor is notified (step 1610 or 161 1). If the copyright policy specifies that the 

15 vendor must give permission for the action (step 1609), the client cannot save the 
results of their action until the user client computer receives permission from the 
vendor (step 1611). Ifpemiission is granted (step 1612). the user can continue 
with their action. If pemiission is denied, the user client computer notifies the 
user and the user's action is not allowed (step 1613). 

20 When tiie user client computer receives a distribution unit containing 

security certificate that specifies the license service (refer to FIG. 17), the user 
client computer allows the user to use the data (step 1703) while the user has a 
valid license (step 1704). If the license has expired, the user client computer 
submits a request for a license renewal containing the security certificate serial 

25 number to the trusted arbitrator (step 1705). If a keycode or registration ID is 
received from the trusted arbitrator (step 1706), the license is renewed (step 
1 707) and the user can use the data. If the license was revoked (step 1 70S), the 
user client computer prevents the user from using the data (step 1709). 
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Referring now lo FIG. 18, when the user client computer receives a 
distribution unit containing a security certificate specifying the subscription 
ser\nce, the user client computer submits a user subscription request containing 
the security certificate serial number and subscriber infomiation (step 1803) to 
5 the trusted arbitrator. When the vendor updates the data and notifies the trusted 
arbitrator, the trusted arbitrator notifies all subscribers to the data (step 1804) and 
the subscribers retrieve the new distribution unit (step 1805). 

A security certificate that specifies the consignment ser\'ice (step 1903 in 
FIG. 19) causes the user client computer to submit a payment request containing 

10 the security certificate serial number and payment information (step 1904) to the 
trusted arbitrator. The user client computer does not allow the data to be used 
until the trusted arbitrator withdraws the payment from the user's account and 
returns a keycode or registration ID (step 1905). The user client computer 
allows the user to use the data (step 1906). 

15 Examples of the security types and policy levels of certificates 

contemplated for use in the present invention are discussed in detail at this point. 
The context in which the information will be used detemiines what security 
scr\'ices and policy enforcement are applicable. As will be readily apparent to 
one of skill in the art. the following examples are not exhaustive and other types 

20 and levels of security certificates can be used with the methods described herein 
without exceeding the scope of the invention. A security certificate can be 
created with a single type and level of security, or different types and varying 
levels of security can be combined into a single security certificate, i.e., 
combining copyrighting with licensing. Furthermore, a trusted arbitrator of the 

25 present invention can offer all or only a subset of the following security 

certificates without depaning from the concepts envisioned by the inventor. 

An exemplary^ format of a security certificate is show^i immediately 
below with a brief description of the major sections following. The remaining 
section of the security cenificate are self-explanatory. Note that multiple or 
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future sen'ices with different policy levels can be combined in the security 
certificate without modifying the original format. 
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SECURITY CERTIFICATE FORMAT 



Header block 

5 Set bytes confinning that this is a security cenificate 

Length of Security Certificate 
Security Certificate Version 

Security Certificate Identifier unique for this certificate 
Time and Date of Registration 
1 0 Number of service blocks (zero or more) 

Application Information Ser\Mce block 

Set bytes confirming that this is an Application Information 
SeiA'ice block 

15 Length of Application Information Serv ice block 

Version of Application Information Serx ice block 
Number of Applications (One or more) 
Application infomiation 

Name of Application 
20 Version of Application 

Number of URLs to find Application 
URL to application 

Number of Services provided by Application 
Services 

25 Editing/Printing/DispIaying/etc 

Author Information Service block 

Set bytes confirming that this is an Author Infomiation Service 
block 

30 Length of Author Infomiation Ser\'ice block 

Version of Author Infomiation Ser\'ice block 
Number of Authors of Data (Zero or more) 
Author infomiation 

Name of Author 
35 Real Author name 

Author's Unique ID 
Anonymous 

No ID given 
Registered (Known to Authenticating Agency) 
40 Unique ID which maps to Author's Unique 

ID 
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Pseudonym (Known to Authenticating Agency) 
Unique Pseudonym which maps to 
Author's Unique ID 

5 

Contact Information 
Name 

Organization or Company 
Address of contact 
10 Email address 

URL 
Phone 

Number of Author Authentication Agencies (zero or 
more) 

1 5 Author Authentication Agency 

Name of Authenticating Agency 

Address 

Email 

URL 

20 

Distributor Infonnation Ser\'ice block 

Set b\tes confirming that this is a Distributor Infomiation Sen ice 
block 

Length of Distributor Infomiation Service block 
25 Version of Distributor Infomiation Sei-vice block 

Number of Distributors (zero or more) 
Distributor information 
Name 

Organization 
30 Site URL 

Email address 

Type of distribution provided 
Download 
Subscription 

35 Consignment 

Bank routing infomiation 
Type of payment accepted 
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Authentication Sen-ice block 

Version of Data Authentication Service 
Number of Data Authenticating Agencies (one or more) 
Data Authenticating Agency 
5 Name of Authenticating Agency ' 

Address 
Email 
URL 

(optional) Signature of digest by Authenticating Agency 

10 

Vahdation Ser\Mce block 

Version of Validation Service 
Name of file validated 

Number of signatures of Authenticating Agency (one or more) 
1 5 Signature 

Name and version of algorithm used 

(optional) Signed security receipt by Authenticating ' 

Agency 

20 Copyright Sendee block 

Version of Copyright Service 
Number of policies (zero or more) 

Copyright Policies (policies can be separate or combined): 
Viewing policy 

25 Must include copyright in view 

Can view freely 

Can view with author notification 
Can view with author pemiission 
Cannot view 

30 Displaying policy 

Must include copyright m display 
Can display freely 
Can display with author notification 
Can display with author permission 

35 Cannot display 

Copying policy 

Whole File and/or Parts (Cut&Paste) 
Must include copyright with new copy 
Can copy freely 

40 Can copy with author notification 

Can copy with author permission 
Cannot copy 
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Distribution policy 

N'lust include copyright in distribution 
Can distribute freely 
Can distribute with author notification 
5 Can distribute with author permission 

Cannot distribute 
Modifying policy 

Must quote source when modified 
Can modify freely 

1 0 Can modify with author notification 

Can modify with author permission 
Cannot modify 
Storing policy 

Can store freely 

1 5 Can store with author notification 

Can store with author permission 
Cannot store 
Caching policy 

Can caclie fi-eely 

20 Can cache with author notification 

Can cache with author pennission 
Cannot cache 

Licensing Sendee block 
25 Version of Licensing Service 

Type of license 

Renewable 
Revocable 
Irrevocable 

30 Number of Licensors (zero or more) 

Licensor hifoniiation 
Name 

Organization or Company 
Address of contact 
35 Email address 

URL 
Phone 

Number of policies (zero or more) 
Licensing policies 
40 Ownership policy 

User must pay before usage 
User can use until license expires 
License revoked at end of subscription 
Number of uses policy 
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Use one or more times 

Unlimited usage 
Number of users and/or machines policy 

One or more concurrent [userjmachine] 
5 No concurrent [usersjmachines] 

Length of time of use policy 

Use only while subscribed to service 
Use for set duration when running 

Use for set duration since installation 
10 Usage ends on Time and Date 

Unlimited 
Credentials policy 

No credentials required 

Adult material (user must be registered as adult) 
15 Groups ( user must be registered with set groups) 

Number of groups 
One or more Group credentials 
Group which has access 
Group Authenticating Agency 
20 Domains (computer address is in set domains) 

Number of domains 

One or more domains which have access 
Network mask for domain 

Passwords 

25 Number of passwords (one or more) 

Passwords which will unlock data 

Subscription Service block 

Version of Subscription Service , 
30 Edition of this data 

Number of policies (zero or more) 
Subscription policies 
Level policy 

All subscribers can access 
35 Subscribers at certain level can access 

Update policy 

Update when original data changed 
Update periodically 

Period to update 
40 Update on payment 

Update on demand 

Consignment Service block 

Version of Consignment Service 
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Number of policies (zero or more) 
Consignment policies 
Cost policy 
Free 

5 Amount per license 

Data Encr\'ption Service block 

Version of Encr>ption Servqce 
Encryption Algorithm used 
1 0 Version of Encryption Algoritlun 

Algorithmic Infomiation 

Users which can unlock data 

Public keys which will unlock data (zero or more) 
Public keys, etc, 

15 

Data Watermark Service block 

Version of Watermark Scr\'ice 
Watemiark Algorithm used 
Version of Watennark Algorithm 
20 Watermark Information 

Data Compression Service block 

Version of Compression Service 
Compression Algorithm used 
25 Version of Compression Algorithm 

Compression hifomiation 

Huffman Data block 
Quantization levels 
etc. 

30 

Installation Ser\''ice block 

Version of Installation Service 
Number of units to install (one or more) 
Unit 

35 Version of unit 

Number of data files in unit (one or more) 
Data file 

Data file name 
Data file size 
40 Flags 

Location after installation 
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Authentication Section 

The trusted arbitrator authenticates the requestor's credentials and returns 
a security certificate containing the information about the trusted arbitrator in the 
5 Authentication Ser\Mce section. An Authentication certificate allows receivers of 
the data to authenticate and validate the vendor as the original author of the data. 

Validation Section 

When a trusted arbitrator provides a security certificate containing the 
Validation Ser^'ice section to a requestor, the trusted arbitrator guarantees to 
10 "validate any digests sent to it against the digest originally sent by the requestor. 
Validation does not prevent others from registering someone else's original 
work, but as long as the originator registers a digest with the trusted arbitrator 
before the work is publicly released, the entry for the originator's digest will be 
earlier than all others. 
1 5 The ti-usted arbitrator can also digitally sign the digest and include the 

signature in the Validation Ser\'ice section. If receivers of the data can validate 
that the signature is correct, they can validate the data without submitting the 
digest to the trusted arbitrator. 
Copvriuhtinu Section 
20 The Copyright Serv ice is available with different levels of policy 

enforcement. The following are examples of levels of policy that can be 
enforced: 

copy freely without author consent, 
modify freely without author consent, 
25 distribute freely w ithout author consent, 

notify author before copy, 
notify author bet'brc modification, 
notify author before distribution, 
no copying, 
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no modification, 
no distribution, 

camiot cut and paste pans of the data, but can copy all data intact, 
must include copyright policy when viewing, 
5 cannot display (in the case of web pages), and 

no caching (in the case of web browsers, routers, and ser\'ers). 

The level(s) of the copyright certificate requested is dependent on the 
data and the policy enforcement desired by the author, i.e., a movie can be 
10 copyrighted to allow the viewer to watch it, but not store it digitally, while 

digital data can be viewed, displayed, but not cached. Different portions of a 
single work can have different copyright policies so that the author of a song can 
copyright the melody and lyrics separately, for example. 

There is also the ability to allow anonymous copyrighting where the user 
15 IS notified that the original author has requested a copyright policy, but the 
security certificate does not reveal the identify of the author to the user. 

Licensing Section 

Licensing policy enforcement can be set for executable code or other 
electronic infonnation through the License Service section of a security 
20 certificate. As with copyrighting, licensing certificates are available in varying 
levels with the following provided as examples: 
X number of uses, 
X number of users, 
expiration date, 
25 user must pay before use, 

user can use only while subscribing to service, 

only users within particular computer domains or user groups can use 
data, 

data must be unlocked by keycode or password before use, 
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revocable, and 
irrevocable. 

The levels of licensing policy can be combined with other policies such 
as the copyright policies. Thus, for example, an author can restrict the user to a 
certain number of uses and also restrict the number of times the user can 
redistribute the infonnation. The keycode or password would be panicular to the 
user so that it unlocks the infomiation one computer but cannot be used to 
unlock the information on another computer. The other computer would have to 
request a new license for the infonnation by sending a new license request to the 
trusted arbitrator with the security certificate serial number. 

Subscription Section 

The author of a work, such as a software application, that wishes to 
provide updates to registered users (subscribers) of the work requests a 
Subscription certificate from the trusted arbitrator. A user is registered as a 
subscriber when it sends the digest containing the subscription certificate on the 
trusted arbitrator. The subscriber's name and address, along with the information 
subscribed to. are stored by the trusted arbitrator. Subscription certificates come 
in var>'ing levels related to certain events, for example: 

infonnation changes (when the author updates the file), 

payment updates (wiien the subscriber pays), 

a time period passes (daily, weekly, monthly, etc), and 

on-demand (when the subscriber requests it). 

The levels of subscription can be combined with licensing so that the 
author requires the subscriber to pay for the information. The type of payment 
can be specified, i.e., pay after a tnal period, pay on installment, or pay per each 
piece of infomiation received. 
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The trusted arbitrator can notify the subscriber of the updates via e-mail, 
by "push** to the user's desktop using technology such as Microsoft's Active 
Channels which allows a user to subscribe to an automatic notification ser\'icc. 
or by pointing the user to an Internet URL (uniform resource locator) where the 
5 user can view/download the new infomiation. The trusted arbitrator can also 
offer an anonymous subscription certificate where the subscriber is notified 
when the author updates the information, but the subscriber's data is held in 
confidence by the trusted arbitrator and not revealed to the author. 

Consignment Section 
10 A consignment certificate causes the trusted arbitrator to enforce a 

payment policy on the user of the electronic infomiation. Consignment 
certificates apply various levels of policy enforcement, for example: 

alert the user periodically (as in so-called "nagware"), 

force the user to pay before running, 
1 5 force the user to pay after a license has expired, 

unlock features after the user paid, and 

e-mail the user with requests to pay. 

Sunimafy 

20 The particular methods perfomied by the server computer for a trusted 

arbitrator of an exemplar\' embodiment of the invention have been described. 
The method performed by the ser\'er has been shown by reference to flowchans 
in FIGs, 7, 8, 9, 10, 11, 12 A, 12B and 13, including the steps from 701 through 
707, SOI through 816, 901 through 906. 1001 through 1012, 1101 through 1113, 

25 1201 through 1224, and 1301 through 1310. 

The particular methods perfonncd by the client computer for a software 
vendor of an exemplar)' embodiment of the invention have been described. The 
method performed by the vendor client computer has been shown by reference to 
flowcharts in FIG. 14, including the steps from 1401 through 140S. 
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The particular methods performed by the cUent computer for a user of an 
exemplary embodiment of the invention have been described. The method 
perfomied by the user client computer has been shown by reference to flowcharts 
inFIGs. 15, 16, 17, 18 and 19. including the steps from 1500 through 1512, 1601 
5 through 1613, 1601 through 1709, 1801 through 1805, and 1901 through 1906. 

Additionally, exemplary embodiments of security certificates for use 
with the methods have been described. The combination of the security 
certificates and methods provide an easy mechanism to protect originators of 
electronic data from misuse while, at the same time, protecting users from 
10 corrupted data. 

Internet implementation 
In this section of the detailed description, a particular implementation of 
the invention is described that provides the security services and policy 
enforcement through standard software applications executing on the client 

1 5 computers when the electronic data is distributed through the Internet. FIG. 20 
illustrate modules, or components, included in the standard software applications 
that cause the client computers to automatically execute the methods described 
in the previous section. The components necessary to implement the methods 
for the ser\''cr computer arc incorporated into standard software used by a 

20 certificate authority or similar trusted third party and are described after the 

components for the clients. As one skilled in the art will readily recognize, the 
components can be written in any executable language and can be routines, 
callable librar\' functions, or objects in an object-oriented environment such as 
Java. 

25 An object is an encapsulated collection of code and data having internal 

functions (methods) that operate on the data and expose external interfaces 
(properties) used to communicate with the object. Objects which can implement 
this invention include, but are not limited to, ActiveX controls which supply a 
standard set of functions in an interface. The ActiveX control would recognize 
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the security certificate format and implement its security ser\*ices and policies. 
Application (web browsers, word processors, paint programs, etc.)r could load 
the ActiveX control and call functions to detennine the con'ect policy to 
implement. The user would not be hindered by the Acti\ eX control and would 
5 inter\'ene only when necessary. 

In this example, assume a publicity agent for a singer uses client 
computer 2000 to create an electronic press release kit to announce the singer's 
new album. The agent wants to include a press release document 2003. a clips 
from the music video for the album 2005, and a text file containing lyrics for the 
1 0 songs of the album 2007. While the agent wants users to freely redistribute the 
entire electronic press release kit and the press release document to gain the most 
exposure for the singer, the agent also needs to protect the video and lyric 
infonnation. 

The agent uses a World Wide Web browser 2009, such as Microsoft 
1 5 Internet Explorer, to connect to a web page on a trusted arbitrator's serx^er 2001 . 
The agent fills out a form on the web page to request security certificates for data 
files 2003, 2005, 2007 and for a distribution unit 2023 that will contain all of the 
data files 2003. 2005, 2007. A security component 201 1 in the browser 2009 
automatically provides to the server the credential information required to 
20 authenticate the agent. 

The security component 201 1 computes the digests 2025, 2027, 2029 and 
2031 of the requested files and their combination, respecti\'ely, using a one-way 
hashing function. The request for the security certificate for the press release 
2003 contains the digest 2025 and the copyright service specifying the "copy 
25 freely" policy. Since the agent wants to protect the video clips from being 

bootlegged, the request for the security cenificate for data file 2005 contains the 
digest 2027 and the copyright ser\*icc specifying the '*view only" policy. The 
lyrics can be copied in whole or in part, but only if they arc attributed to the 
original song writers. The security certificate request for the lyric file 2007 
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contains the digest 2029 and the copyright sen ice specifying the "can copy 
whole file and/or parts, but must include copyright'^ policy. The agent also 
requests a security certificate for the distribution unit 2023 which contains the 
^^copy freely" policy and submits the digest of all the files 2003, 2005, 2007 in 
5 the request. 

The trusted arbitrator returns the security certificates 2013, 2014 and 
2015 for the files 2003, 2005 and 2007, respectively, and returns 2016 for the 
distribution unit 2023. The agent packages each security certificate with its data 
and creates a nested distribution unit 2023 which ser\ es as the press release kit. 
1 0 The agent requests that the browser 2009 upload the press release kit 2023 to 
several web sites that specialize in music entertainment 2040. 

A user browsing one of the music entertainment sites 2040 sees an 
announcement regarding the press release kit. When the user clicks on a link to 
the press release kit, the distribution unit 2023 is downloaded to the client 
15 (user's) computer 2002. A security component 2035 in the user's browser 2033 
extracts the security certificates 2013, 2014, 2015 of all the files 2003, 2005, 
2007 in the distribution unit 2023 and the security certificate20 16 of the 
distribution unit 2023. The security component 2035 computes digests 2025, 
2027, 2029, 2031 from the data files 2003, 2005, 2007 and the distribution unit 
20 2023, connects to the tmsted arbitrator's ser\'er 2001 , and submits a validate 

request to the trusted arbitrator's ser\'er 2001. The validate request contains the 
serial numbers of the security certificates 2013, 2014, 2015, 2016 and the digests 
2025, 2027, 2029, 2031. 

Once the validation is complete, the security component 2035 in the 
25 browser 2033 allows the user to view the data. The browser 2033 now displays 
the press release document 2003 and lyrics 2007 to the user and can play the 
music video 2005. However, if the user attempts to save the lyrics 2007 in 
whole or in part to a different location on the computer 2002, the security 
component 2035 in the browser 2033 copies the original copyright notice 
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aiiribuiing the lyrics to the original author. If the user attempts lo modify or 
copy the music video to a different location, the security component 2035 in the 
browser 2033 notifies the user that the music video is view only and cannot be 
copied or modified. notifies 
5 When the user exits the browser 2033, the user can access the press 

release document 2003, the video clip 2005, and the lyric file 2007 through their 
''native" applications 2037, such as Microsoft Word and Microsoft Media Player. 
When the user requests that the native application 2037 open one of the items 
2003, 2005, 2007 in the press release kit, a security component 2039 in the 

10 native appHcation 2037 uses the associated security certificate 2013, 2014. 2015 
to determine the proper uses of the item. If the user requests the native 
application 2037 copy or modify the item, the security component 2039 in the 
native application 2037 notifies the user of the improper use and aborts the. 
operation. In the embodiment illustrated in FIG. 20, the securit\' components 

15 2035 and 2039 are shown as separate modules. Alternate embodiments in which 
the same security module is shared among all software executing on the user's 
computer which need to validate data are considered within the scope of the 
invention. 

The sender 2001 for the trusted arbitrator executes standard server 
20 software containing three components that provide the ser\Mces required by the 
client computer. Because. the components are considered to be well within the 
understanding of one of skill in the art based on the details provided in the 
previous section, the components are not illustrated in FIG. 20. 

A ser\'er security module creates the security certificates 2013, 2014, 
25 2015. 2016 when the ser\'*cr 2001 receives the request from the client computer 
2000 and returns the security certificates to the client computer 2000. A 
registration module logs the digests 2025, 2027, 2029, 2031 received from the 
client computer 2000 into the verification log and returns the time stamped 
receipts to the client computer. A ser\'er security module compares the digest 
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received from the client computer 2002 with the logged digest and returns 
validation messages when the digests match. 

This section has described a particular implementation of the security 
ser\^ices and policy enforcement for electronic data provided by components 
5 within standard software applications running on a client computer. The 

components can be provided as add-on modules, such as applets downloaded for 
use in a browser, or can be incorporated in the software as a standard feature. 
This section has also described a particular implementation of the security 
ser\'*ices and policy enforcement for electronic data provided by components 
10 within standard ser\ er software. 

Conclusion 

A series of transactions and security certificates have been described 
w^hich authenticate and validate electronic data and also enforce restrictions on 
the use of that data. The transaction functions are performed by components 

1 5 within standard software applications based on the security type and policy level 
of a security certificate included with the data. 

Thus, the present invention guarantees the authenticity and validity of the 
electronic data and enforce use restrictions on the data through the use of the 
certificates. Furthemiore, the verification log ser\'es to memorialize the author 

20 and creation lime of the data since the ser\'er has authenticated an author prior to 
creating the certificate and lime stamps the certificate and the digest that is 
generated from the electronic data. Because the client functions are 
automatically provided by modules, or components, in standard software, the 
author and the user do not have to concern themselves with complicated 

25 encryption/decryption schemes. The ser\'er functions are additional components 
to send er software that already provides electronic certificates. 

Although specific embodiments have been illustrated and described 
herein, it will be appreciated by those of ordinary skill in the art that any 
arrangement which is calculated to achieve the same purpose may be substituted 
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for the specific embodiments shown. This application is intended to cover any 
adaptations or variations of the present invention. 

The terminology used in this appHcation with respect to is meant to 
include all hardware and software platfomis. Therefore, it is manifestly intended 
5 that this invention be limited only by the following claims and equivalents 
thereof 
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What is claimed is: 

1 . A computerized method for providing security ser\'ices and policy 
enforcement for electronic data, the method comprising the steps of: 

submitting, by a first client, a certificate request to a ser\'er; 
5 receiving, by the ser\'er, the certificate request, authenticating the first 

client, generating a certificate, registering the certificate, and transmittmg the 
certificate to the first client; 

receiving, by the first client, the certificate, creating an authenticated file 
containing the certificate and a distribution unit, generating a first digest from 
10 the authenticated file using a hashing algoritlim. and submitting the first digest to 
the server; 

time stamping, by the server, the digest, logging the digest, and 
transmitting a time stamped receipt to the first client; 

acquiring, by a second client, the authenticated file, generating a second 
15 digest from the authenticated file using the hashing algorithm, and submitting 
the second digest to the server; and 

receiving, by the ser\^er, the second digest, comparing the second digest 
to the logged first digest, and transmitting a message to the second client as a 
result of the comparison. 

20 

2. The computerized method of claim 1 . wherein the certificate requested is 
a security certificate. 

3. The computerized method of claim 1 . wherein the certificate requested is 
25 a subscription certificate and further comprising the steps of: 

registering, by the serv^er, the second client as having the authenticated 

file; 

creating, by the first client, an update authenticated file containing the 
certificate and an updated version of the distribution unit, generating an update 
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digest from the update authenticated file using the hashing algorithm, and 
submitting the update digest to the sen'er; 

receiving, by the ser\'er, time stamping and logging the update digest, and 
returning a time stamped update receipt to the first client; and 

determining, by the ser\'er, that the second client has the authenticated 
file and notifying the second client of the update authenticated file. 

4. The computerized method of claim K wherein the certificate requested is 
a policy enforcement certificate. 

5. The computerized method of claim 4, further comprising the steps of: 
generating, by the second client, a notification that the data in the 

distribution unit is being used inappropriately based on a policy level specified 
in the certificate 

receiving, by the ser\'er, the inappropriate use notification; and 
notifying the first client of the inappropriate use. 

6. The computerized method of claim 4, wherein the message returned b\ 
the server to the second client requests the second client pay for the authenticated 

20 file and further comprising the steps of: 

receiving, by the ser\'er, a payment from the second client; and 
transmitting, by the ser\'er, a key to unlock data in the distribution unit. 

7. A computer-readable medium having computer-executable instructions to 
25 a cause a ser\'er computer to perfomi a method comprising: 

creating a certificate in response to receiving a certificate request from an 
authenticated first client; 

registering the certificate as held by the first client; 
transmitting the certificate to the first client; 

49 



10 



15 



wo 00/42492 



PCT/USOO/00716 



loaaina a digest received from the first client using a first time stamp; 
comparing a digest received from a second client with the logged digest; 

and 

transmitting a comparison result message to the second client. 

5 

8. The computer-readable medium of claim 7, further comprising the steps 
of: 

receiving a notification that the second client is using data associated 
with the logged digest inappropriately based on a policy level specified in the 

10 certificate; and 

transmitting a notification of inappropriate use to the first client. 

9. The computer-readable medium of claim 7, further comprising the steps 
of 

15 registering the second client as having data associated with the logged 

digest; 

logging an update digest received from the first client using a second 
time stamp; 

reluming an update receipt to the first client; and 
20 notifying the second client of that the data associated with the logged 

digest has been updated. 

10. The computer-readable medium of claim 7, further comprising the steps 

of: 

25 transmitting a request for payment to the second client; 

receiving payment from the second client; and 
transmitting a key to unlock data associated with the logged digest. 
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11. A computer-readable medium having computer-executable instructions to 
a cause a client computer to perfonn a method comprising: 

transmitting a certificate request to a server; 
receiving a certificate from the ser\'er; 
5 generating a digest from the certificate combined with a distribution unit 

using a hashing algoritlim; 

transmitting the digest to the server; and 

receiving a time stamped confirmation message for the digest from the 

server. 

10 

12. The computer-readable medium 1 1 , wherein the method further 
comprises receiving an inappropriate use message from the server. 

13. The computer-readable medium of claim 1 1, wherein the method further 
15 comprises: 

generating an update digest from the certificate and an updated version of 
the distribution unit; 

transmitting the update digest to the ser\'er; and 

receiving a time stamped confinnation message for the update digest 
20 from the ser\'er. 

14. A computer-readable medium having computer-executable instructions to 
a cause a client computer to perform a method comprising: 

generating a digest from a certificate and a distribution unit received by 
25 the client; 

transmitting the digest to a ser\'er; and 

receiving a message from the server as a result of transmitting the digest. 
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15. The computer-readable medium of claim 14, wherein the method further 
comprises: 

determining that data in the distribution unit is being used inappropriately 
based on a policy level specified in the certificate; 
5 alerting a user of the client computer of the inappropriate use; and 

transmitting a notification message to the server regarding the 
inappropriate use if the user continues the use. 

16. The computer-readable medium of claim 14, wherein the method further 
10 comprises receiving an update notification from the serv-er that data in the 

distribution unit has been updated. 

17. The computer-readable medium of claim 14, wherein the method further 
comprises: 

1 5 receiving a payment request from the server; 

transmitting a payment to the server; and 

receiving a key from the ser\'er to unlock data in the distribution unit. 

18. A computer system comprising: 
20 a processing unit; 

a system memory coupled to the processing unit through a system bus; 

a computer-readable medium coupled to the processing unit through a 
system bus; and a client application executed from the computer-readable 

medium by the processing unit, wherein the client application comprises: 
25 a validation module that causes the processing unit to generate a digest 

from an authenticated file received by the processing unit, to submit the digest to 
a ser\'er, and to receive a message from the serx^er as a result of submitting the 
digest. 
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19. The computer system of claim IS, wherein the validation module funher 
causes the processing unit to receive an update notification from the ser\'er. 

20. The computer system of claim 1 8, wherein the validation module further 
5 causes the processing unit to receive a payment request from the server, to 

submit payment to the ser\'er in response to the payment request, and to receive a 
key to unlock data in the authenticated file. 

2K The computer system of claim 18, wherein the validation module further 
10 causes the processing unit to detect inappropriate use of data in the authenticated 
file based on a policy level specified in a certificate in the authenticated file, to 
notify a user of the computer of the inappropriate use, and to submit an 
inappropriate use message to the server if the use continues. 

15 22. The computer system of claim 18, wherein the client application further 
comprises: 

an authentication module that causes the processing unit to create a request for a 
certificate, to submit the request to a server, to combine a distribution unit and 
the certificate received from the serx'er into an authenticated file, to generate a 
20 digest from the authenticated file using a hashing algorithm, to submit the digest 
to the serv er, and to receive a confirmation message from the server. 

23. The computer system of claim 22, wherein the authentication module 
further causes the processing unit to combine an updated version of the 
25 distribution unit and the certificate into an update authenticated file, to generate 
an digest from the update authenticated file using the hashing algorithm, to 
submit the update digest to the ser\^er. and to receive an update confirmation 
message from the serv'er. 
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24. The computer system of claim 22, wherein the authentication module 
further causes the processing unit to receive an inappropriate use notification 
message from the server. 

5 25. A computer system comprising: 
a processing unit; 

a system memory coupled to the processing unit through a system bus; 
a computer-readable medium coupled to the processing unit through a 
system bus; and a client application executed from the computer-readable 

10 medium by the processing unit, wherein the client application comprises: 
an authentication module that causes the processing unit to create a 
request for a certificate, to submit the request to a server, to combine a 
distribution unit and the certificate received from the server into an authenticated 
file, to generate a digest from the authenticated file, to submit the digest to the 
15 serv^er, and to receive a confirmation message from the server. 

26. The computer system of claim 25, wherein the authentication module 
further causes the processing unit to combine an updated version of the 
distribution unit and the certificate into an update authenticated file, to generate 

20 an digest from the update authenticated file using the hashing algorithm, to 
submit the update digest to the ser\^er, and to receive an update confimiation 
message from the server. 

27. The computer system of claim 25, wherein the authentication module 
25 further causes the processing unit to receive an inappropriate use notification 

message from the server. 

28- A computer system comprising: 
a processing unit; 
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a system memory coupled to the processing unit through a system bus; 

a computer-readable medium coupled to the processing unit through a 
system bus; and a client application executed from the computer-readable 
medium by the processing unit, wherein the client application comprises: 
5 a security module that causes the processing unit to detect inappropriate 

use of data in an authenticated file based on a policy level specified in a 
certificate in the authenticated file, to notify a user of the computer of the 
inappropriate use, and to submit an inappropriate use message to a server if the 
use continues. 

10 

29. A computer system comprising: 
a processing unit; 

a system memor>' coupled to the processing unit through a system bus; 

a computer-readable medium coupled to the processing unit through a 
15 system bus; and a server application executed from the computer-readable 
medium by the processing unit, wherein the client application comprises: 

a certificate module that causes the processing unit to create a certificate 
in response to receiving a certificate request from an authenticated requesting 
client, to register the certificate, and to transmit the certificate to the requesting; 
20 a registration module that causes the processing unit to log a digest with a 

time stamp in response to receiving the digest, and to return a confirmation 
message; and 

a security module that causes the processing unit to compare a digest 
received by the processing unit against the logged digest, and to transmit a 
25 message as a result of the comparison. 

30. The computer system of claim 29, wherein the security module causes 
the processing unit to receive, from a client, an inappropriate use message based 
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on a policy level specified in the certificate and to notify the client that requested 
the certificate of the inappropriate use. 

3 1 . The computer system of claim 29, wherein the message transmitting by 
5 the security module as a result of the comparison is a payment request, and the 
security module further causes the processing unit to receive a pavonent and to 
transmit a key in response to receiving the payment. 

32- A computer-readable medium having stored thereon a security certificate 
10 data structure comprising: 

a header data field containing data representing an identifier for a security 
certificate; and 

a services block data field containing data representing a service to be 
enforced by the security certificate identified by the header data field. 

15 

33. The computer-readable medium of claim 32, wherein the data 
representing the ser\Mce is selected from the group consisting of authentication 
data, validation data, copyright data, licensing data, subscription data, and 
consignment data. 

20 

34. A computer-readable medium having stored thereon a verification log 
data structure comprising: 

a file name data field containing data representing a name for a data file; 
a timestamp data field containing data representing a time associated with 
25 the data file identified by the file name data field; 

a security certificate data field containing data representing an identifier 
for a security certificate associated with the data file identified by the file name 
data field; and 
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a digest data field containing data representing a hash of the data file 
identified by the file name data field. 
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updates to the data, notification of improper user of the data, 
and payment for the use of the data. 
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